Server controlled throttling of client to server requests

ABSTRACT

Embodiments of the invention provide methodologies for server-controlled throttling of client to server requests in order to improve client-server communication performance. Embodiments of the invention relate to systems and methods that provide routines for real-time monitoring of requests originating from client devices, for analyzing the characteristics of the requests, for developing protocols for managing requests within a client-server infrastructure, and for facilitating client adherence to the developed protocols. The systems and methods contemplated by the present invention involve means for monitoring the requests received by servers from client devices, means for analyzing the characteristics of the requests, means for developing client-server communication protocols intended to improve client-server communication performance, and means for delivering the protocols to a plurality of client devices.

BACKGROUND

In recent years, advances in computer processors and wireless networkshave engendered a proliferation of mobile computing devices. Thepopularity of smart phones, tablet computers, wearable computerizeddevices, and a variety of other devices has increased dramatically inrecent years. Advances at the hardware level have enabled such devicesto be made increasingly smaller and more portable and thereby increasedconsumer demand for such devices. Simultaneously, software advances havedramatically increased the array of features such computerized devicesprovide. Many software services rely on resources provided by remotelylocated servers. In order to access and utilize such resources, mobiledevices communicate with the remotely located servers through a varietyof both wireless and wired networks. However, the capacity of suchservers to connect and share resources with clients is inherentlylimited. As the number of mobile devices has increased, the burden onserver networks has also increased, and the risk that a server maybecome overwhelmed with requests from client devices has increased aswell. Heavy traffic client request can result in considerabledegradation of server performance by consuming server resources. Inextreme cases, heavy client traffic can render the server entirelyunable to provide requested resources to clients.

SUMMARY

Embodiments of the invention provide methodologies for server-controlledthrottling of client to server requests in order to improveclient-server communication performance. Embodiments of the inventionrelate to systems and methods that provide routines for real-timemonitoring of requests originating from client devices, for analyzingthe characteristics of the requests, for developing protocols formanaging requests within a client-server infrastructure, and forfacilitating client adherence to the developed protocols. The systemsand methods contemplated by the present invention involve means formonitoring the requests received by servers from client devices, meansfor analyzing the characteristics of the requests, means for developingclient-server communication protocols intended to improve client-servercommunication performance, and means for delivering the protocols to aplurality of client devices. The network traffic managementfunctionality may by implemented by a computer system that comprisesinstructions stored in a non-transitory computer-readable medium and oneor more processors that execute the instructions.

Client devices often adhere to particular procedures in attempting toacquire resources from a server. A client transmits a request forresources to a server and then waits for a response from the server.Client software often specifies a maximum time for which the client willwait for a response from a server. If the maximum wait time is reached,the client will deem the request as failed and retransmit the request.Typically, client software also specifies a maximum number of requestretries, and if the maximum number of retries is reached without theclient receiving the requested resource from the server, the client maydeem the resource to be unavailable or take other remedial action. Themaximum wait time, or socket timeout, and the request retry limit may bespecified by the client operating system, by client network interfacesoftware, or by the network carrier that the client utilizes fortransmission of requests to the server. These client-servercommunication parameters, i.e. the socket timeout and request retrylimit, may vary based on the type of request or based on aclassification of the type of resource being requested. However, thevalues of these communication parameters are typically static, i.e. theydo not change in response to behavior of the server, to behavior ofother client devices, or to external conditions that impactcommunications between the client and the server. Clients are generallyunable to account for external factors in setting the values of theclient server communication parameters. The inability of clients toresponse to dynamic external factors can result in clients sending anexcessive number of resource requests and thereby causing a degradationin client-server communication performance through wasteful consumptionof server resources.

Embodiments of the present invention utilize the capabilities of aserver to aggregate data corresponding to requests issued to the serverby vast numbers of remotely located clients. Embodiments of the presentinvention further utilize the capabilities of computer processors toanalyze the aggregated data in real time and to determine whether or notcommunication between the clients and the server could be improvedthrough a modification of client-server communication parametersutilized by clients in requesting resources from the server. In theevent that the processing routines encompassed by the present inventiondetermine that a modification of the client-server communicationparameters could improve client-server communication performance, theprocessing routines may further calculate updated client servercommunication parameters and transmit the updated parameters to theclient devices. In this manner, the present invention enables a serverto throttle client requests based on information aggregated from thevarious client devices. The server therefore functions as a centralizedrequest management authority that accounts for the totality of clientactivity in prescribing procedures for client server communications.

One implementation contemplates a method, implemented by one or moreprocessors executing instructions stored at computer-readable storagemedia, for throttling client-to-server resource requests, the methodcomprising producing one or more data sets, wherein each data setcomprises a plurality of data points representing a characteristic of aninstance of client-server communication, determining whether a conditionfor triggering a client-server communication parameter update has beenmet, and when a condition for triggering a client-server communicationparameter update has been met, calculating updated client-servercommunication parameters, and transmitting the updated client-servercommunication parameters to one or more clients.

Another implementation contemplates a server comprising a processor anda computer readable storage medium having stored thereon processorexecutable instructions, the server further comprising a client-servercommunication monitoring module configured to produce one or more datasets and to determine whether a condition for triggering a client-servercommunication parameter update has been met, a client-servercommunication analysis module configured to calculate updatedclient-server communication parameters, and a client commandtransmission module configured to transmit the updated client-servercommunication parameters to one or more clients, wherein each data setcomprises a plurality of data points representing a characteristic of aninstance of client-server communication.

An additional implementation contemplates a system for server-controlledthrottling of client-to-server requests, the system comprising a servercomprising a processor and a computer readable storage medium, theserver configured to, produce one or more data sets, wherein each dataset comprises a plurality of data points representing a characteristicof an instance of client-server communication, determine whether acondition for triggering a client-server communication parameter updatehas been met, calculate updated client-server communication parameters,and transmit the updated client-server communication parameters to aclient, and a client comprising a processor and a computer readablestorage medium, the client configured to transmit a request to theserver, receive the updated client-server communication parameters fromthe server, and implement procedures for transmitting requests to theserver that utilize the updated client-server communication parameters.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an example environment in which themethodologies for server-controlled throttling of client-to-serverrequests may be implemented;

FIG. 2 is a block diagram of the basic functional components for anexample server depicted in FIG. 1, according to one aspect of thedisclosure;

FIG. 3 is a block diagram of the basic functional components for anexample client depicted in FIG. 1, according to one aspect of thedisclosure;

FIG. 4 is a flow diagram illustrating an example method, implemented ata server, for server controlled throttling of client server requests;

FIG. 5 is a flow diagram illustrating an example process for updatingclient-server communication parameters implemented at a client device ina system for server controlled throttling of client-server requests.

DETAILED DESCRIPTION

FIG. 1 is a block diagram of an example environment in whichmethodologies for facilitating user interaction with the user's presentenvironment may be implemented. In the example environment depicted inFIG. 1, clients 101A and 101B through 101N are connected to a network102. The network 102 enables the clients 101 to communicate with aserver 103. The server 103 is further connected to a database 104.Database 104 stores a variety of information pertaining to user accountsmanaged by the server 103.

Clients 101 may be any of a smart phone, a personal digital assistant(PDA), a tablet computer, a wearable computer, a laptop computer, avideo-game console, or any one of a number of additional devices thatmay establish communicative connections with a server over a network.Clients 101 are capable of sending information to and receivinginformation from the server 103. The clients 101 may receive data andinformation that is pushed from the server 103 and may also receivetransmissions of data and information that are responsive to requestspreviously sent by the clients 101 to the server 103. For example,clients 101 may request a web page or a file from the server 103 and mayreceive the requested web page or file from the server 103. The clients101 may also receive push notifications from the server 103.

The network 102 connects the clients 101 to the server 103. The network102 may be either a wired or a wireless network, and may includeelements of a cellular network, a voice over internet protocol (VoIP)network, a public switched telephone network (PSTN), or a combinationthereof. Example networks include but are not limited to an LTE network,a GSM network, a CDMA network, a fiber optic network, and other voice ordata networks. The network 102 may also include elements of WLAN or WPANnetworks that enable the clients 101 to connect to other components ofthe network, for example an LTE network. The network 102 may include aset of cell towers, as well as a set of base stations and/or mobileswitching centers (MSCs). As appreciated by those skilled in the art,the network 102 may include various cell tower/base station/MSCarrangements. For example, a base station and a cell tower could beco-located at the same site or they could be remotely located, and asingle base station could be coupled to various cell towers or variousbase stations could be coupled to a single MSC, to name but a few of thepossible arrangements. Alternatively or in addition to theaforementioned components of the network 102, the network 102 mayinclude one or more IP multimedia subsystems (IMS), serving gateways(SGW), and evolved node Bs (eNB). One of ordinary skill in the art willrecognize that additional components not mentioned herein may be used bythe network 102.

The server 103 comprises processors and memory configured to receiverequests for information from the clients 101 and to provide data andinformation to the clients 101. The server 103 is further configured toaggregate data pertaining to the requests transmitted by the clients 101and to analyze the aggregated data. The data aggregated by the servermay include a variety of information pertaining to the clients 101 thatis not limited to data pertaining to a user account affiliated with aclient, data pertaining to the user-facing latency encountered by aclient in transmitting a request to a server, data pertaining to backendlatency and on the wire latency associated with requests transmittedfrom the client to the server, data pertaining to client-to-servercommunication procedures practiced by a client, data pertaining to thegeographic location of a client, data pertaining to a wireless carrierutilized by a client for communication with the server 103, contextualdata pertaining to a client, and a variety of additional information.The server 103 may further include processors and memory configured tocalculate updated client server communication procedures intended toimprove the communication between the server and the multitude ofclients 101.

Processors and memory located at the user-environment interaction server103 may also be configured to both access information stored at adatabase and to store information at a database, such as database 104.For example, the server 103 may be configured to store informationpertaining to data and statistics that are representative of therequests transmitted by the clients 101 to the server 103. Furthermore,the server 103 may be configured to request data representative ofprevious data and statistics corresponding to requests transmitted byclients to the server 103.

The server 103 is also connected to the database 104. The database 104may store a variety of information, including, e.g., informationpertaining to one or more user accounts. Information pertaining to theone or more user accounts may include but is not limited to a useraccount name, the name of a user to whom the user account belongs, analias for the user account, verification information for the useraccount, a social network profile associated with the user account,images associated with the user account, documents and media contentassociated with the user account, and various user account settings.Furthermore, database 104 may also store a variety of data pertaining toclient-server communication performance and client request statistics.

Embodiments of the invention that may be practiced in the exampleenvironment represented by FIG. 1 are generally drawn towards managingrequests that are issued by clients and directed to one or more servers.Embodiments of the invention contemplate monitoring, in real-time, datapertaining to requests issued to a particular server (or to a particulargroup of servers) by clients that are members of a particular class.Data points can be obtained for each request issued by a particularclient and the data points corresponding to clients that are members ofa particular class can be aggregated to form a data set representativeof the class. For example, data points for each request sent by a clientthat utilizes a particular wireless carrier may be aggregated inreal-time in order to produce a data set representative of the class ofclients that subscribe to the particular wireless carrier. Similarly,the data points might be selected from requests transmitted by clientsthat are members of a class defined by a particular geographic area.Class of clients may also be defined by multiple conditions, e.g.clients that subscribe to a particular wireless carrier that are alsolocated in a particular geographic location. Furthermore, dataoriginating from a single client may be included in multiple data setsif that single client is a member of multiple classes.

Embodiments of the invention further contemplate detecting a clientrequest throttling trigger during monitoring of the request datarepresentative of a particular class. A variety of client requestthrottling triggers may be specified for a variety of different classesof clients. In general, client request throttling triggers correspond tosituations where an adjustment in the client request parameters for aclass of clients is likely to result in a reduction in the mean ormedian latency experienced by the clients in the class or to result inotherwise improved client-server communication. In some implementations,the client request throttling triggers may correspond to predeterminedstatistical thresholds. For example, if the median latency experiencedby members of a class of clients exceeds a threshold, a client requestthrottling process is triggered. Alternatively, events may trigger thethrottling of client requests. For example, the release of new contenton a server that is expected to draw a large number of requests fromclients may trigger the throttling of client requests by the server.Similarly, changes to a wireless network or to another network utilizedby clients to transmit requests to a server may trigger the throttlingof client requests by the server.

Embodiments of the invention also contemplate the calculation, by theserver, of updated client server communication parameters. The updatedparameters can be transmitted to the clients in order to throttle therequests transmitted by the clients and thereby improve client servercommunications. In order to calculate updated client-servercommunication parameters, the systems and methods of the presentinvention may consult a variety of contextual and historical data thatis relevant to the particular class of clients for which the clientrequest throttling trigger is detected. For example, in calculatingclient server communication parameters, the systems and methods of thepresent invention may utilize characteristics of distributions of clientrequest data points, historical client server communication performanceunder similar circumstances corresponding to analogous events,historical client-server communication performance at the same time ofday, month, or year, specific characteristics of each client device anduser account associated with each client device, and a variety ofadditional information.

Furthermore, certain embodiments of the present invention contemplatethe distribution of the calculated client-server communicationparameters from the server to the clients that are members of the classfor which the parameters have been calculated. In variousimplementations, the transmission of the client-server parameters to theclients may be executed in various manners. In some implementations, theserver may transmit the updated parameters in response to furtherrequests issued by the clients. For example, the server may affix aheader to responses to client requests where the header specifies theupdated client-server parameters. Alternatively, the server may transmitthe updated client-server parameters to the clients that are members ofthe class for which the parameters have been calculated in a broadcastor multicast.

Through the monitoring of client-server requests and other client-servernetwork traffic attributable to particular classes of clients, thepresent invention enables a server to detect network issues that areconfined to particular classes of clients. The server is thereby able tocalculate client-server communication parameters that are uniquelytailored to a particular class of clients. The present invention thusenables a server to independently manage client-server communicationparameters for multiple classes of clients and thereby improve themedian latency experienced by all clients in the aggregate. Furthermore,by detecting issues that are specific to a particular class of clients,the present invention can prevent a network issue that is confined to aparticular class of clients from resulting in a distributed denial ofservice (DDOS) attack that renders the server inaccessible to allclients.

FIG. 2 is a block diagram of the basic functional components for theserver 103 depicted in FIG. 1, according to one aspect of thedisclosure. The server 103 includes one or more processors 201, memory202, a network interface 203, one or more storage devices 204, and aclient-server request management engine 305. In a conventional fashion,each of components 201, 202, 203, 204, and 205 are interconnectedphysically, communicatively, and/or operatively for inter-componentcommunications. The server 103 may be a web server, a file server, mayfunction as both a web server and a file server under differentcircumstances, or may be any other type of server.

As illustrated, processors 201 are configured to implement functionalityand/or process instructions for execution within user-environmentinteraction server 200. For example, processors 201 execute instructionsstored in memory 202 or instructions stored on storage devices 204.Memory 202, which may be a non-transient, computer-readable storagemedium, is configured to store information within server 103 duringoperation. In some embodiments, memory 202 includes a temporary memory,i.e. an area for information to be maintained when the server 103 isturned off. Examples of such temporary memory include volatile memoriessuch as random access memories (RAM), dynamic random access memories(DRAM), and static random access memories (SRAM). Memory 202 alsomaintains program instructions for execution by the processors 201.

Storage devices 204 also include one or more non-transientcomputer-readable storage media. Storage devices 204 are generallyconfigured to store larger amounts of information than memory 202.Storage devices 204 may further be configured for long-term storage ofinformation. In some examples, storage devices 204 include non-volatilestorage elements. Non-limiting examples of non-volatile storage elementsinclude magnetic hard discs, optical discs, floppy discs, flashmemories, or forms of electrically programmable memories (EPROM) orelectrically erasable and programmable (EEPROM) memories.

The user-environment interaction server 200 uses network interface 203to communicate with external devices via one or more networks, such asthe network 102 of FIG. 1. Such networks may include one or morewireless networks, wired networks, fiber optics networks, and othertypes of networks through which communication between the server 103 andan external device may be established. Network interface 203 may be anetwork interface card, such as an Ethernet card, an opticaltransceiver, a radio frequency transceiver, or any other type of devicethat can send and receive information.

Client-server communication management engine 205 is configured toreceive information pertaining to requests made to the server 103 fromone of the clients 101 and to aggregate data pertaining to the requestsreceived by the server from a multitude of clients. Specifically,client-server communication management engine is configured to .Client-server communication management engine 205 includes client-servercommunication monitoring module 211, client-server communicationanalysis module 212, and client command transmission module 213.

Client-server communication monitoring module 211 is configured tomonitor requests received from clients 101 and develop data pertainingto the requests received from the clients. The client-servercommunication monitoring module 211 may further establish side channelswith one or more of the multiple clients that transmit requests to theserver 103. Alternatively, the client-server communication monitoringmodule 211 may receive data or information from a distinct entity thatis utilized to establish side-channel communication with clients 101.The client-server communication monitoring module 211 is configured toclassify clients into one or more classes based on a variety ofcharacteristics of the client being classified. The client may beclassified based on the wireless carrier to which the client subscribes,based on a particular segment of a wireless network that the clientutilizes, based on geographic location, based on type of device, basedon the user account with which the client is affiliated, and based on avariety of additional characteristics of the client. The client-servercommunication monitoring module 211 is further configured to developdata sets that include data points that are representative of thecommunications between the server 103 and the individual clients 101.Data sets may be established for each of the classes into which theclient-server communication monitoring module categorizes the individualclient devices.

Client-server communication analysis module is configured to analyze thecharacteristics of data aggregated by the client-server communicationmonitoring module and to determine whether or not the performance of thecommunication between the server 103 and classes of clients can beimproved through modification of current client-server communicationparameters or otherwise. Furthermore, client-server communicationanalysis module is configured to calculate updated client-servercommunication parameters to improve the communication flow between theserver 103 and the multitude of client devices 101.

Client command transmission module 213 is configured to transmit updatedclient-server communication parameters to the clients 101. In variousimplementations, the client command transmission module 213 mayfacilitate a broadcast of updated communication parameters, a multicastof updated communication parameters, or may facilitate the addition of aheader including updated communication parameters to data packetsresponsive to client requests.

While FIG. 2 depicts a single server entity that both receives resourcerequests from clients, provides resources to clients, and monitors andanalyzes traffic flow from various classes of clients to the server,alternative configurations are possible. For example, the traffic flowanalysis and monitoring may be performed by a processor executinginstructions stored at a machine-readable medium located remotely fromthe other elements of the server. In various implementations of thepresent invention, the hardware utilized to implement the functionalityof the server 103 may be distributed across multiple ostensibly distinctdevices or may be located at a single device.

Turning now to FIG. 3, a block diagram of the basic functionalcomponents for an example client of FIG. 1 is depicted. In general, manyother embodiments of the client 101 may be used as long as theembodiment is capable of transmitting data to a server and receivingdata from a server over one or more network interfaces. In theembodiment illustrated by FIG. 3, the client 101 includes one or moreprocessors 301, memory 302, a network interface 303, one or more storagedevices 304, a power source 305, one or more output devices 360, and oneor more input devices 380. The client 101 also includes an operatingsystem 310 that is executable by the client 101, and further includes anetwork communication management engine 311. In some implementations,the network communication management engine 211 may be a component ofthe operating system 310 (as is depicted by FIG. 3). In alternativeimplementations, the network communication management engine may beseparate and distinct from the operating system 310 or may compriseelements of the operating system 310 as well as elements that areexternal to the operating system 310. In a conventional fashion, each ofcomponents 301, 302, 303, 304, 305, 310, 311, 360, and 380 areinterconnected physically, communicatively, and/or operatively forinter-component communications.

As illustrated, processors 301 are configured to implement functionalityand/or process instructions for execution within the client 101. Forexample, processors 301 execute instructions stored in memory 302 orinstructions stored on storage devices 304. Memory 302, which may be anon-transient, computer-readable storage medium, is configured to storeinformation within the client 101 during operation. In some embodiments,memory 302 includes a temporary memory, i.e. an area for information tobe maintained when the client 101 is turned off. Examples of suchtemporary memory include volatile memories such as random accessmemories (RAM), dynamic random access memories (DRAM), and static randomaccess memories (SRAM). Memory 302 also maintains program instructionsfor execution by the processors 301.

The client 101 uses network interface 303 to communicate with externaldevices via one or more networks, such as the network 104 of FIG. 1. Thenetwork interface 303 may include multiple interfaces for connectingwith various types of networks. Such networks may include one or morewireless networks, wired networks, fiber optics networks, and othertypes of networks through which communication between the client 101 andan external device may be established. Network interface 303 may includea network interface card, such as an Ethernet card, an opticaltransceiver, a radio frequency transceiver, or any other type of devicethat can send and receive information. Other non-limiting examples ofinterfaces that may be included in the network interface 303 includeBluetooth, 3G and WiFi radios as well as USB interfaces.

Storage devices 304 also include one or more non-transientcomputer-readable storage media. Storage devices 304 are generallyconfigured to store larger amounts of information than memory 302.Storage devices 304 may further be configured for long-term storage ofinformation. In some examples, storage devices 304 include non-volatilestorage elements. Non-limiting examples of non-volatile storage elementsinclude magnetic hard discs, optical discs, floppy discs, flashmemories, or forms of electrically programmable memories (EPROM) orelectrically erasable and programmable (EEPROM) memories.

The client 101 includes one or more power sources 305 to provide powerto the client. Non-limiting examples of power source 305 includesingle-use power sources, rechargeable power sources, and/or powersources developed from nickel-cadmium, lithium-ion, or other suitablematerial.

The client 101 includes one or more input devices 380. Input devices 380are configured to receive input from a user through tactile, audio,and/or video feedback. Non-limiting examples of input device 380 includea presence-sensitive screen, a keyboard, a voice responsive system, avideo camera, a microphone, and any other type of device for detecting acommand from a user. In some examples, a presence-sensitive screenincludes a touch-sensitive screen.

One or more output devices 360 are also included in client 101. Outputdevices 360 are configured to provide output to a user using tactile,audio, and/or video stimuli. Output device 360 may include a displayscreen (which may be part of a presence-sensitive screen), a sound card,a video graphics adapter card, or any other type of device forconverting a signal into an appropriate form understandable to humans ormachines. Additional examples of output device 360 include a speaker, aliquid crystal display (LCD), or any other type of device that cangenerate intelligible output to a user.

The client 101 includes an operating system 310, such as the Android®operating system. The operating system 310 controls operations of thecomponents of the client 101. For example, the operating system 310facilitates the interaction of the processors 301, memory 302, networkinterface 303, storage device(s) 304, input device 380, output device360, and power source 305.

The client 101 further includes a network communication managementengine 311. In various implementations the network communicationmanagement engine 211 may be a component of the operating system 310,may comprise components of the operating system 310, or may be distinctfrom the operating system 310. The environment analysis engine 311 isconfigured with processor executable instructions. Such processorexecutable instructions may facilitate the interaction of the processors301, memory 302, network interface 303, storage device(s) 304, outputdevice 360, input device 380, and motion sensors 390. The networkcommunication management engine 311 is configured to control and managethe connections initiated by the client 101 through the networkinterface 303. The network communication management engine 311 maydetermine the protocols by which various connections are established andmay specify process steps by which the connections are initiated andterminated. In particular, the network communication management engine311 may determine procedures and rules by which requests are transmittedto web servers and file servers. Specifically, the communicationmanagement engine may specify communication parameters for connectionswith a server. Such communication parameters may include but are notlimited to a socket timeout (the amount of time the client will wait fora response from a server after sending a request to the server beforeretransmitting the request) and a retry limit (the maximum number oftimes a request may be transmitted by the client before the clientexecutes an alternative action). The network communication managementengine 311 may maintain a variety of different communication parametersthat correspond to a variety of different server. For example, ifapplications are installed on the client that utilize a particularserver, the network communication management engine 311 may maintainunique communication parameters for each unique server that utilized byeach of the applications.

FIG. 4 is a flow diagram illustrating an example method, implemented ata server, for server controlled throttling of client server requests. At402, the server 103 develops updated client-server communication data.The updated client-server communication data developed at 103 isdeveloped via real time analysis of requests received by the server 103.In some implementations, the analysis of incoming requests may beperformed by a specific processing module within the server 103, e.g.the client-server communication module 211 of the client-server requestmanagement engine 205. For example, data packets received by the networkinterface 203 of the server 103 may be analyzed by the client-serverrequest management engine 205 in order to identify characteristics ofthe client from which the data packet originated. The analysis of thereceived requests may also identify of characteristics of the networkthrough which the data packets were transmitted. The server 103 may alsodevelop client-server communication data through information or dataprovided to the server 103 by a client. For example, the client maytransmit a message that indicates the current user-facing latencyexperienced by the client.

The development of updated client-server communication data furtherinvolves segmenting the data according to various classes of clients.Clients may be classified according to their mobile network carrier,their geographic location, their device type, the characteristics of acorresponding user account, IP address, and a variety of othercharacteristics. Clients may be classified first according to a primarycharacteristic, and thereafter, the class defined by the primarycharacteristic may be further classified according to secondarycharacteristics. Additional classifications of subclasses may also beutilized in various implementations. For example, a particular class ofclients may be defined according to the mobile network carrier, and allclients that utilize a particular mobile network carrier may be furtherclassified based upon the geographic location of the device. Theclassifications may be determined according to a variety of algorithmsand processing routines stored at computer readable storage media withinthe server, e.g. the storage devices 204, and executed by processors201.

Development of client-server communication data at 402 involvesaggregating data points representative of the requests received fromvarious clients into data sets that correspond to the classes ofclients. For example, data points representative of each requestreceived from clients that utilize a particular wireless network carriermay be aggregated into a data set that is representative of the class ofclients that utilize the particular wireless carrier. In variousimplementations, the data points utilized to produce a data set mayinclude various types of information. For example, the data points mayinclude information corresponding to user-facing latency, current sockettimeout utilized by the client, the current number of retries allowed bythe client, the current backend latency associated with the processingof a request, the current on-the-wire latency associated with aclient-to-server request, and a variety of other types of data.

The process may also develop a variety of different data sets for eachclass of clients where the different data sets accumulate data overvarious time windows. Multiple data sets for user-facing latency (or anyother client-server communication characteristic) experienced by aparticular class of clients may be produced in which each data setconsists of data points obtained during time windows of variousduration. A first data set may consist only of data points that werereceived within the previous thirty seconds, a second data set mightconsist of data points that were received within the previous fiveminutes, and a third data set may include all data points that werereceived within the previous hour.

At 404, statistics of the aggregated client-server communication dataare calculated for each of the various classes of clients. Inparticular, for each data set developed at 402, statistics of the dataset are calculated at 404. Various types of regressions may be used tobest approximate the data corresponding to each of the data setsdeveloped at 402. For example, a distribution of user-facing latency forclients that utilize a particular wireless carrier network may bemodeled with a Gaussian regression. Modeling the distribution of datapoints in a data set corresponding to a particular characteristic ofclient-to-server requests for a particular class of clients allows themean, median, and variance of the data set to be determined.Furthermore, modeling the distribution of data points enables acumulative distribution function to be developed for each data set. Inaddition to modeling the distributions of data in the data setsdeveloped at 402 through Gaussian regression, a variety of other typesof regression may be utilized by the process.

At 406, the process determines whether or not a trigger for aclient-server communication parameter update has been detected. If notrigger is detected, the process returns to 402. However, if a triggeris detected, the process proceeds to 408.

In various implementations, triggers may be defined based on thestatistics calculated at 404, based on historical network performancedata, based on information pertaining to events that may impact networkperformance, based on a combination thereof, or based on additionalcriteria. For example, the statistical information calculated at 404 maybe used to define triggers for updating client-server communicationparameters. For example, if it is determined that some percentage ofrequests issued by a particular class of clients experience a latencythat exceeds a predetermined threshold, a client-server communicationparameter update may be triggered. For statistical triggers, thresholdsmay be determined according to current client-server communicationparameters. For example, a socket timeout client-server communicationparameter of ten seconds may correspond to an update trigger having ahigher threshold connection failure time than a socket timeoutclient-server parameter of five seconds. Triggers may also vary based onthe duration of the time window over which data points in a particulardata set are accumulated. In some implementations, triggers may bedefined based on statistical information for multiple data sets wheredifferent data sets are weighted differently. For example, the processmay calculate a composite throttling score at 406 where the compositescore is based on a sum of individual scores calculated for variousindividual data sets. Triggers may be defined by various compositethrottling scores.

Other triggers for client-server parameter updates may correspond toevents that are likely to impact the performance of a particularwireless network. For example, wireless carriers may reset a usage limiton a monthly basis at a predetermined time. A trigger for aclient-server communication parameter update may be tied to thepredetermined time at which the wireless carrier will reset the monthlyusage limit. Thus, a client-server communication parameter update may betriggered by the time approaching that at which the wireless carrierwill reset the usage limit. Other events that are not wireless networkspecific may impact the performance of multiple wireless networks andcreate triggers for client-server communication parameter updates. Forexample, a sporting event that attracts hundreds of thousands of peopleto a confined area with limited access to cellular towers or otherwireless network resources may cause the performance of the wirelessnetworks to suffer a considerable reduction within those geographicareas. Therefore, a client-server communication parameter update may betriggered for all clients within the confined geographic area at thetime at which the event is set to take place. Similarly, a naturaldisaster impacting a particular geographic area may result in greaterthan average network traffic directed from clients within the geographicarea to one or more particular servers, e.g. a weather server. Undersuch circumstances, the weather server could issue a client-serverparameter update designed to account for the anticipated increase innetwork traffic.

Additional triggers for client-server parameter updates may notcorrespond to particular events but may instead be determined based uponperiodic usage cycles. For example, a client-server communicationparameter update may be triggered based on the transition from a firstsegment of a day to a second segment of a day and may be locationspecific. For example, decreased usage at particular times of day maycorrespond to one set of client-server parameters and the transition toa time of day characterized by greater usage may trigger an update inclient-server parameters. Similarly, monthly and annual cycles may bedefined and transitions from time periods characterized by higher usageto time periods characterized by lower usage—or vice versa—may triggeran update of the client-server communication parameters.

At 408, the server aggregates additional contextual and historicalclient-server communication data. The additional contextual andhistorical client-server data accumulated at 408 corresponds to theparticular trigger that was detected at 406. For example, if the triggerthat was detected at 406 was an event based trigger that prescribes aclient-server communication parameter update as a result of the timeapproaching a time at which an event is scheduled to start, the processmay query an external database, such as the database 104, in order toacquire additional information pertaining to the event. For example, ifthe trigger is the detection of a natural disaster that is likely toimpact a particular geographic area, the server may query additionalinformation pertaining to the natural disaster, e.g. the severity of thedisaster and the geographic areas it is likely to impact. Furthermore,the server may request historical data pertaining to circumstancessimilar to those that gave rise to the trigger at 406. For example, ifthe trigger is the upcoming release of new media content on a mediacontent server, historical data pertaining to downloads of similar mediacontent in the past may be queried. Similarly, contextual informationspecific to the particular item that is to be released may bedownloaded. For example, if the content is a wildly successful moviethat may attract significant numbers of downloads, the magnitude of theimpact of the release-triggered downloading may be indicated by thebox-office success of the movie and the impact of the release of othermovies that had similar box-office performances.

At 410, the process calculates updated, class-specific client-servercommunication parameters. In various implementations, various differentclient-server communication parameters may be specified by the process.Such client-server communication parameters may include but are notlimited to socket timeout, i.e. the time limit after which a requestthat does not receive a response is re-tried, and a total number ofallowed request retries before a request is deemed to be failed. In someimplementations, the process may define particular baseline values forthe client-server communication parameters based upon a set of baselineconditions. For example, a combination of time of day, time of month,and time of year may be used to define a set of baseline client-servercommunication parameters. Time of day, month, and year combinations thathave historically corresponded to periods of relatively low wirelessnetwork latency and backend latency may correspond to client-serverparameters of relatively low timeout thresholds and relatively highretry limits. By contrast, time of day, month, and year combinationsthat have historically corresponded to periods of relatively highwireless network latency and backend latency may correspond torelatively high timeout thresholds and relatively low retry limits. Inthis manner, the process may set threshold client-server communicationparameters that are designed to limit the number of requests issued byclients during periods of time when carrier network traffic is likely tobe high an to allow clients to issue larger number of requests and issuethose requests more frequently when network traffic is likely to be low.

Furthermore, triggers detected at 406 and the statistics calculated at404 may be utilized by the process to calculate a unique set ofclient-server parameters tailored to each class of clients and to thespecific situation faced by each class. Specifically, the statisticscalculated at 404 and the specific triggers detected at 406 maydetermine the values of the client-server communication parameterscalculated at 410. In some implementations, particular client-servercommunication parameters may be mapped to particular triggers. Forexample, the client-server communication parameters calculated at 410may be determined exclusively by the trigger that was detected at 406.In other implementations, the processing routines utilized to calculatethe client-server communication parameters may take into accountspecific statistical information calculated at 404. In suchimplementations, the processing routines utilized to calculate theclient-server communication parameters at 410 use various quantitativestatistical inputs that correspond to the statistics calculated at 404.For example, the client-server communication parameters may bedetermined based on the mean or median user-facing latency and thestandard deviation or variance of the user-facing latency. Incalculating the client-server communication parameters, the processingroutines may also use statistical values of distributions related to thebackend latency associated with the processing of a client request, theon-the-wire latency associated with a client request, and other types ofdata.

The contextual data and historical client-server communication dataacquired by the server at 408 may also be utilized in determining theupdated client-server communication parameters at 410. For example, inthe event that a trigger is tied to a time at which a wireless carrieror server will reset a limit on the amount of data that an individualclient or local network can transmit and receive over a period of timeprior, historical data aggregated by the server at 408 may be utilizedin calculating the updated parameters. For example, the server 103 mayanalyze data pertaining to client-server requests from various clientclassifications immediately after such a data limit reset occurred andcalculate the updated client-server communication parameters based onsuch historical data. The process may also take into account the numberof members of each class that have reached the data limit in determiningthe updated client server communication parameters. For example, theserver may calculate client-server communication parameters that aredesigned to limit network traffic more aggressively in the event that aparticularly large percentage of the client class has met the datalimit. By contrast, the process may calculate client-servercommunication parameters that are designed to limit network traffic lessaggressively in the event that a smaller percent of the members of theclient class has met the data limit.

In some implementations, the statistics calculated at 404 and thetriggers detected at 406 may be utilized in conjunction with thecontextual and historical information aggregated at 408 in order tocalculate the updated class-specific client-server communicationparameters at 410. The processing routines may consider a variety ofinformation pertaining to each class of clients when determining theclass-specific client-server communication parameters and may utilizedifferent information for different classes. In some implementations,the processing routines utilized to calculate the updated client serverparameters at 410 will utilize a variety of inputs in calculating theupdated client server parameters. The inputs may include but are notlimited to characteristics of distributions of client request datapoints, historical client-server communication performance correspondingto contextual situations similar to the present contextual situationfacing the server, historical client-server communication performance atthe same time of day, month, or year, specific characteristics of eachclient device and user account associated with each client device, and avariety of additional information.

At 412, the updated client-server communication parameters aretransmitted to the class of clients for which they were calculated. Invarious implementations, the updated parameters can be transmitted invarious manners. In some implementations, the updated parameters arebroadcast, or multicast, to the clients that make up the class for whichthe updated parameters were calculated. For example, the updatedparameters may be transmitted to all clients that utilize a particularwireless carrier. Alternatively, the updated parameters may be broadcastwithin a particular geographic location and all clients within range ofthe broadcast will receive the updated parameters. In furtherimplementations, the updated parameters may be affixed to responses toclient requests. For example, the updated parameters may be included ina header of the response.

FIG. 5 is a flow diagram illustrating an example process for updatingclient-server communication parameters implemented at a client in asystem for server controlled throttling of client-server requests. At502, the client 101 transmits a request to the server 103. At 504, theclient determines whether or not a request was received prior to thesocket timeout client-server communication parameter has been reached.If a message is received before the socket timeout limit is reached, theprocess proceeds to 512. However, if no message is received before thesocket timeout limit is reached, the process proceeds to 506.

At 506, the process determines whether or not the retry parameter limithas been reached. The retry parameter is a client server communicationparameter that determines the number of times that a client will retrysending a request before determining that the server resource isunavailable. If the process determines at 506 that the number of retrieshas been exceeded, the process proceeds to 510 where the clientidentifies the resource as unavailable. Thereafter, the process ends.However, if the number of retries has not been exceeded, the processproceeds to 508, where a retry counter is incremented, and then returnsto 502 where the request is transmitted again.

At 512, the client determines whether or not the response issued by theserver is indicative of a client-server communication parameter update.If the process determines that the response does indicate aclient-server communication parameter update, the process proceeds to514 where the client updates its client-server communication parameters.Thereafter the process ends.

In various implementations, the server 103 may instruct the client toupdate the client-server communication parameters in a variety ofmanners. In the embodiment depicted by the flow chart in FIG. 5, theserver 103 instructs the client to update the client-servercommunication parameters in a response to a request issued by theclient. The instruction to update the parameters may be carried in aheader of a packet that is responsive to the request issued by theclient but may also be carried in the payload of the packet. Inalternative implementations, the server 103 may instruct the client 101to update the client-server communication parameters through packetsthat are pushed to the client 101 and not responsive to any requestissued by the client. response indicate that the client-servercommunication parameters are to be updated in a variety of differentmanners. In some implementations, the

It is contemplated that other implementations may differ in detail fromthe foregoing examples. As such, all references are intended toreference the particular implementation being discussed at that point inthe description and are not intended to imply any limitation as to thescope of the invention more generally. All language of distinction anddisparagement with respect to certain features is intended to indicate alack of preference for those features, but not to exclude such from thescope of the invention entirely unless otherwise indicated.

For situations in which the systems discussed here collect personalinformation about users, or may make use of personal information, theusers may be provided with an opportunity to control whether programs orfeatures collect personal information (e.g., information about a user'ssocial network, social actions or activities, profession, a user'spreferences, or a user's current location), or to control whether and/orhow to retrieve content from a content server. In addition, certain datamay be anonymized in one or more ways before it is stored or used, sothat personally identifiable information is removed. For example, auser's identity may be anonymized so that no personally identifiableinformation can be determined for the user, or a user's geographiclocation may be generalized where location information is obtained (suchas, for example, to a city, ZIP code, or state level), so that aparticular location of a user cannot be determined. Thus, the user mayhave control over how information is collected about him or her and usedby the systems discussed herein.

The use of the terms “a” and “an” and “the” and “at least one” andsimilar referents in the context of describing the disclosed subjectmatter (especially in the context of the following claims) are to beconstrued to cover both the singular and the plural, unless otherwiseindicated herein or clearly contradicted by context. The use of the term“at least one” followed by a list of one or more items (for example, “atleast one of A and B”) is to be construed to mean one item selected fromthe listed items (A or B) or any combination of two or more of thelisted items (A and B), unless otherwise indicated herein or clearlycontradicted by context. The terms “comprising,” “having,” “including,”and “containing” are to be construed as open-ended terms (i.e., meaning“including, but not limited to,”) unless otherwise noted. Recitation ofranges of values herein are merely intended to serve as a shorthandmethod of referring individually to each separate value falling withinthe range, unless otherwise indicated herein, and each separate value isincorporated into the specification as if it were individually recitedherein. All methods described herein can be performed in any suitableorder unless otherwise indicated herein or otherwise clearlycontradicted by context. The use of any and all examples, or examplelanguage (e.g., “such as”) provided herein, is intended merely to betterilluminate the disclosed subject matter and does not pose a limitationon the scope of the invention unless otherwise claimed. No language inthe specification should be construed as indicating any non-claimedelement as essential to the practice of the invention.

Variations of the embodiments disclosed herein may become apparent tothose of ordinary skill in the art upon reading the foregoingdescription. Skilled artisans may employ such variations as appropriate,and the invention to be practiced otherwise than as specificallydescribed herein. Accordingly, this invention includes all modificationsand equivalents of the subject matter recited in the claims appendedhereto as permitted by applicable law. Moreover, any combination of theabove-described elements in all possible variations thereof isencompassed by the invention unless otherwise indicated herein orotherwise clearly contradicted by context.

The invention claimed is:
 1. A method comprising: generating, by aserver, one or more data sets, wherein each data set from the one ormore data sets includes a plurality of data points representing acharacteristic of an instance of client-server communication between arespective client from a plurality of clients and the server, whereineach data point from the plurality of data points represents one or moreof: a user-facing latency associated with a client-to-server request, abackend latency associated with processing of the client-to-serverrequest, and an on-the-wire latency associated with the processing ofthe client-to-server request; determining, by the server and based atleast in part on the one or more data sets, whether a condition fortriggering a client-server communication parameter update has been met;and responsive to determining that the condition for triggering theclient-server communication parameter update has been met: calculating,by the server, updated client-server communication parameters includingat least an updated request retry limit identifying a maximum number ofretries that the respective client from the plurality of clients areable to attempt prior to determining that a resource is unavailable; andtransmitting, by the server and to one or more clients of the pluralityof clients, the updated client-server communication parameters.
 2. Themethod of claim 1, wherein the updated client-server communicationparameters further include a socket timeout.
 3. The method of claim 1,wherein each client from the plurality of clients is a member of aunique class of clients.
 4. The method of claim 3, wherein the class ofclients is defined by one or more of: a network carrier, a geographiclocation, a characteristic of an affiliated user account, an IP addressrange, and a type of client device.
 5. The method of claim 1, whereindetermining whether a condition for triggering a client-servercommunication parameter update has been met comprises: calculating, bythe server, statistical characteristics of the one or more data sets;and determining, by the server, whether the statistical characteristicsof one of the one or more data sets exceeds a threshold.
 6. The methodof claim 5, further comprising: determining, by the server and based oncurrent values of the client-server communication parameters, thethreshold.
 7. The method of claim 1, wherein calculating updatedclient-server communication parameters is based at least in part on oneor more of: statistical characteristics of the one or more data sets,historical client-server communication performance, and occurrence of anevent.
 8. The method of claim 7, wherein the event comprises one or moreof: a server reset of a data transfer limit, a network carrier reset ofa data transfer limit, and release of new content at the server.
 9. Themethod of claim 1, wherein transmitting the updated client-servercommunication parameters to one or more clients comprises one of:transmitting the updated client-server communication parameters in aheader of a response to a client request, transmitting the updatedclient-server communication parameters in a payload of a response to aclient request, and transmitting the updated client-server communicationparameters via a push notification.
 10. The method of claim 9, whereintransmitting the updated client-server communication parameters via thepush notification comprises one of: transmitting the updatedclient-server communication parameters via a broadcast, and transmittingthe updated client-server communication parameters via a multicast. 11.A device comprising: a processor; and a computer readable storage mediumhaving stored thereon one or more modules executable by the processorto: generate one or more data sets, wherein each data set from the oneor more data sets includes a plurality of data points representing acharacteristic of an instance of client-server communication between arespective client forma plurality of clients and the device, whereineach data point from the plurality of data points represents one or moreof: a user-facing latency associated with a client-to-server request, abackend latency associated with processing of the client-to-serverrequest, and an on-the-wire latency associated with the processing ofthe client-to-server request; determine, based at least in part on theone or more data sets, whether a condition for triggering aclient-server communication parameter update has been met; andresponsive to determining that the condition for triggering theclient-server communication parameter update has been met: calculateupdated client-server communication parameters including at least anupdated request retry limit identifying a maximum number of retries thatthe respective client from the plurality of clients are able to attemptprior to determining that a resource is unavailable; and transmit, toone or more clients of the plurality of clients, the updatedclient-server communication parameters.
 12. The server of claim 11,wherein the updated client-server communication parameters furtherinclude a socket timeout.
 13. The server of claim 11, wherein each datapoint in each data set corresponds to an instance of client-servercommunication involving a client that is a member of a unique class ofclients.
 14. The server of claim 13, wherein the class of clients isdefined by one or more of: a network carrier, a geographic location, acharacteristic of an affiliated user account, an IP address range, and atype of client device.
 15. The server of claim 11, wherein the one ormore modules are executable by the processor to determine whether thecondition for triggering the client-server communication parameterupdate by at least being executable by the processor to: calculatestatistical characteristics of the one or more data sets; and determinewhether the statistical characteristics of one of the one or more datasets exceeds a threshold.
 16. A non-transitory computer-readable storagemedium encoded with instructions that, when executed, cause one or moreprocessors of a computing device to: generate one or more data sets,wherein each data set from the one or more data sets includes aplurality of data points representing a characteristic of an instance ofclient-server communication between a respective client from a pluralityof clients and the device, wherein each data point from the plurality ofdata points represents one or more of: a user-facing latency associatedwith a client-to-server request, a backend latency associated withprocessing of the client-to-server request, and an on-the-wire latencyassociated with the processing of the client-to-server request;determine, based at least in part on the one or more data sets, whethera condition for triggering a client-server communication parameterupdate has been met; and responsive to determining that the conditionfor triggering the client-server communication parameter update has beenmet: calculate updated client-server communication parameters includingat least an updated request retry limit identifying a maximum number ofretries that the respective client from the plurality of clients areable to attempt prior to determining that a resource is unavailable; andtransmit, to one or more clients of the plurality of clients, theupdated client-server communication parameters.
 17. The non-transitorycomputer-readable storage medium of claim 16, wherein each data point ineach data set corresponds to an instance of client-server communicationinvolving a client that is a member of a unique class of clients, andwherein the class of clients is defined by one or more of a networkcarrier, a geographic location, a characteristic of an affiliated useraccount, an IP address range, or a type of client device.
 18. Thenon-transitory computer-readable storage medium of claim 16, wherein theinstructions further cause the one or more processors to: calculatestatistical characteristics of the one or more data sets; and determinewhether the statistical characteristics of one of the one or more datasets exceeds a threshold.
 19. The non-transitory computer-readablestorage medium of claim 16, wherein the updated client-servercommunication parameters are calculated based at least in part on one ormore of: statistical characteristics of the one or more data sets,historical client-server communication performance, and occurrence of anevent.
 20. The device of claim 11, wherein the updated client-servercommunication parameters are calculated based at least in part on one ormore of: statistical characteristics of the one or more data sets,historical client-server communication performance, and occurrence of anevent.